home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000108_owner-urn-ietf _Thu Oct 24 16:41:43 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  5KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA19048 for urn-ietf-out; Thu, 24 Oct 1996 16:41:43 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA19042 for <urn-ietf@services.bunyip.com>; Thu, 24 Oct 1996 16:41:38 -0400
  3. From: jayhawk@ds.internic.net
  4. Received: from cagw2.att.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  5.         id AA29877  (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 16:41:34 -0400
  6. Received: from qsun.ho.att.com by caig2.att.att.com (SMI-8.6/EMS-1.2 sol2)
  7.     id QAA07284; Thu, 24 Oct 1996 16:43:52 -0400
  8. Received: from qsun2.ho.att.com.qsun2 by qsun.ho.att.com (4.1/EMS-1.1.1 SunOS)
  9.     id AA01126; Thu, 24 Oct 96 16:41:22 EDT
  10. Received: from sloop ([135.16.157.189]) by qsun2.ho.att.com.qsun2 (5.x/EMS-1.2 sol2)
  11.     id AA05679; Thu, 24 Oct 1996 16:40:17 -0400
  12. Message-Id: <9610242040.AA05679@qsun2.ho.att.com.qsun2>
  13. Original-From: "Ryan Moats" <jayhawk@ds.internic.net>
  14. To: "Martin J Duerst" <mduerst@ifi.unizh.ch>
  15. Cc: "URN mailing list" <urn-ietf@bunyip.com>
  16. Date: Thu, 24 Oct 96 15:46:15 
  17. Priority: Normal
  18. X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE
  19. Mime-Version: 1.0
  20. Content-Type: text/plain; charset="us-ascii"
  21. Content-Transfer-Encoding: 7bit
  22. Subject: Re: [URN] Unicode for NSS query
  23. Sender: owner-urn-ietf@services.bunyip.com
  24. Precedence: bulk
  25. Reply-To: jayhawk@ds.internic.net
  26. Errors-To: owner-urn-ietf@bunyip.com
  27.  
  28. On Thu, 24 Oct 1996 21:47:41 +0100 (MET), Martin J Duerst wrote:
  29.  
  30. >>
  31. >>On Thu, 24 Oct 1996, Martin J Duerst wrote:
  32. >>
  33. >>> 
  34. >>> I have suggested that we might be required to thing in terms of
  35. >>> both characters and octets. For some things, similar to a data:
  36. >>> URL, thinking in characters might be artificial. For some
  37. >>> other things, such as URLs, thinking in octets may to some
  38. >>> extent be necessary because of backwards compatibility issues
  39. >>> (assume an URL scheme is extended and decides to use some
  40. >>> weird RFC 1522-like method for encoding characters, and this
  41. >>> would have to be grandfathered).
  42. >>>
  43. >>
  44. >>I have thought about the same thing, and I admit that I am not altogether
  45. >>enthusiastic about RFC 1522 style encoding of URNs, but it may be forced
  46. >>upon us. 
  47. >
  48. >Well, I didn't mean that this is currently the case. The ftp
  49. >i18n extensions, for example, are happily going in the direction
  50. >of UTF-8 and would very well fit together with our proposal.
  51. >
  52. >But I have made the experience that trying to specify UNicode only
  53. >can meet quite some resistance. Some people, for whatever reasons,
  54. >are strongly anti-unicode. If you specify something like
  55. >"urns use Unicode and nothing else", they may start to complain.
  56. >If you say "urns should use Unicode, and clients should interpret
  57. >urns as Unicode if possible, but if really necessary, an NSS
  58. >can use something else" then it's difficult to oppose, even
  59. >if maybe in actual practice, there will not be a single NSS
  60. >that ever specifies something else than Unicode.
  61.  
  62. Huh?  My "knee-jerk" reaction is that by saying that client should convert from
  63. an NSS that isn't in Unicode(10646)/UTF-8 shall be converted before
  64. being sent to the URN resolver handles this nicely.  I include in this statement
  65. the act of entering a NSS at an interface in some other encoding (ASCII, etc.)
  66.  
  67. >NSSs or URL shemes (I still have problems distingushing them)
  68. >themselves might also do the same thing, namely saying that
  69. >in general, character semantics should be ISO 10646/UTF-8, but
  70. >that other things would be tolerated for backwards compatibility.
  71. >This is exactly the case for ftp, where a lot of 8-bit filenames
  72. >are already existing and in use, although not UTF-8.
  73.  
  74. I'm not sure I'm comfortable with this.  My view is that the documentation of the NID
  75. would specify this as an exception to the syntax document and the syntax document
  76. says "here's the syntax, but exceptions are allowed for namespaces that document 
  77. there exceptions elsewhere?  Seems awfully kludgy to me...
  78.  
  79. >It is also important because not every arbitrary sequence of
  80. >8-bit octets is an UTF-8 sequence. What should browsers, resolvers,
  81. >and all the other components of our URN arichitecture do with
  82. >these?
  83.  
  84. I expect that anything that tries to resolve a sequence of 8-bit octets that aren't a
  85. UTF-8 sequence should fail, unless the namespace has provided information otherwise.
  86. I see this as related to the above issue:  The two basic choices are:
  87.  
  88. (1) Allow things other than UTF-8 (and force the exceptions to be documented as
  89. part of namespace registration).  The resolvers then have to use the namespace
  90. specific information (including exceptions).  (2) Do not allow other than UTF-8 and
  91. reject the arbitrary 8-bit octet sequence as unresolvable if it is unresolvable.
  92.  
  93. The first is cleaner from the point of view of the end-users, the second from the point
  94. of view of internal clenliness.
  95.  
  96. Ryan
  97.